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REMARKS 

Claims 1-21 and 23-28 are pending. 

Request for Withdrawal of the Finality of the Office Action 

The applicants respectfully request that the finality of the present Office Action be 
withdrawn, because it is improper. M.P.E.P. § 706.07(a) states that "[u]nder present practice, 
second or any subsequent actions on the merits shall be final, except where the examiner 
introduces a new ground of rejection that is neither necessitated by applicant's amendment of 
the claims, nor based on information submitted in an information disclosure statement 
The Section 101 rejection of claims 1-10, 21 and 23-28 was presented for the first time in the 
present Office Action and thus represents "a new ground of rejection." The Section 101 
rejection was not necessitated by any amendments submitted by the applicants (the applicants 
did not amend the claims in the last reply dated Oct. 9, 2008). Nor was the Section 101 
rejection necessitated by any IDS filed by the applicants. Consequently, the finality of the 
Office Action is improper and should be withdrawn. 

Claim Rejections under 35 U.S.C. § 101 

Independent claims 1 and 21 have been amended to address the Examiner's objections 
to claims 1-10 and 21, 23-28 under Section 101. No new matter is added by these 
amendments. As amended, these claims are directed to statutory subject matter. 
Reconsideration is respectfully requested. 

Claims 1 1-20 are indicated in paragraph 4 of the Office Action as "fall[ing] under a 
statutory class of producing a tangible result." Accordingly, no amendments have been made 
to those claims. 

Claim Rejections under 35 U.S.C. §102 

The Examiner has maintained the rejection of claims 1-21 and 23-28 under 35 U.S.C. 
§ 102(b) as being anticipated by non-patent literature titled "ARIES: A Transaction Recovery 
Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write- Ahead 
Logging," by C. Mohan et al., ACM Transactions on Database Systems, vol. 17, no. 1, March 



Page 7 of 10 



DOCKET NO.: MSFT-2732/305554.01 
Application No.: 10/782,988 
Office Action Dated: 01/15/2009 



PATENT 



1992, pages 94-162 (hereinafter referred to as "Mohan"). Reconsideration is respectfiiUy 
requested. 

As explained in response to the previous Office Action, Mohan does not teach 
"marking the changed data page to indicate that the transaction log buffer has yet to be 
flushed to a persistent data store," as recited in each of independent claims 1,11 and 21. As 
explained in the specification at paragraphs [0027] - [0034], this enables a system that allows 
"lazy-commits" of transactions to still provide a "durable read" of data subject to a lazy 
commit to applications that want a durable read of that data. The Examiner's attempt to read 
the claimed "marking" step on the writing of the LSN field of a data page, as described in 
Mohan, is misplaced. 

Specifically, in paragraph 2 of the Office Action, the Examiner "interprets the LSN 
field as marking the change data page to indicate the transaction log buffer (i.e., log record) 
has yet to be flushed to a persistent data store." But the LSN field of a data page does 
nothing to indicate whether a particular log record (or an entire log buffer) has been flushed 
to persistent storage. The LSN field of a data page simply provides a sequence number that 
associates the changed page with its corresponding log record in the transaction log buffer. 
The applicants provide a good description of LSNs in paragraph [0023] of the present 
specification: 

[0023] For every change that is written to any of the data pages 214, 
a corresponding log record describing the change is written 230 to the 
transaction log buffer 210 (step 2). Every log record generated is 
given a sequence number referred to as a Log Sequence Number 
(LSN). This LSN is also written 248 to the data page 204 in an 
attribute called Page LSN 250 (step 3). Page LSN means the LSN of 
the last log record corresponding to the last change made to the page. 

Mohan provides the same description of LSNs on page 96 (Section 1.1): 

To meet transaction and data recovery guarantees, ARIES records in a 
log the progress of a transaction, and its actions which cause changes 
to recoverable data objects . . . Every log record is assigned a unique 
log sequence number (LSN) when that record is appended to the log. 
The LSNs are assigned in ascending sequence. Typically, they are the 
logical addresses of the corresponding log records. 

{italics in original). But the LSN field of a data page (i.e,, the "Page LSN" attribute) does not 

in any way indicate whether the transaction log buffer, or any particular record in that buffer. 
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has been flushed to persistent storage. That is why in the claimed method, the changed data 
page is marked to indicate that the transaction log buffer containing the log record for that 
page has yet to be flushed to persistent storage. Mohan does not teach or suggest such a step, 
which is not surprising because Mohan does not appear to address the problem solved by the 
applicants - how to provide a "durable read" in a system that allows "lazy commits" of 
transactions. 

In asserting that the LSN field of a data page is the same as the claimed "marking" 

step, the Examiner further asserts that "The Examiner believes that it is inherent that when 

log records are written that they are written to a persistent data store." That is incorrect. Log 

records are first saved to a transaction log buffer in memory (volatile storage), and it is only 

when that log buffer is flushed that the records in the buffer are written to a persistent data 

store. Mohan explains this very clearly at the bottom of page 96 (Section 1.1): 

Whenever log records are written, they are placed first only in the 
volatile storage (i.e., virtual storage) buffers of the log file. Only at 
certain times (e.g., at commit time) are the log records up to a certain 
point (LSN) written, in log page sequence, to stable storage. This is 
called forcing [or flushing] the log up to that LSN. 

(italics in original). Thus, the Examiner's belief "that it is inherent that when log records are 

written that they are written to a persistent data store," is incorrect. 

Because Mohan fails to teach or suggest the claimed step of "marking the changed 

data page to indicate that the transaction log buffer has yet to be flushed to a persistent data 

store," as recited in each of independent claims 1,11 and 21, those claims are not anticipated 

by Mohan. Inasmuch as the remaining claims depend from one of those independent claims, 

they too are not anticipated by Mohan for the same reason. Withdrawal of the Section 102 

rejection of claims 1-21 and 23-28 is respectfiiUy requested. 

CONCLUSION 

For all the foregoing reasons, the applicants respectfully submit that the present 
application is now in condition for allowance. 
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